Unless it's something brand new and super unknown -- as I understand the current bind vulnerablity that Paul Vixie mentioned here has nothing to do with DNS spoofing-via-altering-the-glue records, although I was pointed out a few months ago, that a forward lookup in gethostbyaddr() of 4.9.2 and prior versions was vulnerable to a quite trivial DNS spoofing, the details are quite trivial: if a "black hat" wants to get onto spoofed.boom.net and runs DNS for foobar.net -- he just needs to alter an "A" record for spoofed.boom.net, add: spoofed.boom.net CNAME some_of_his_sites. some_of_his_sites. A [real ip # of some_of_his_sites goes here] some_of_his_sites. A [ip # of spoofed.boom.net] The reverse lookup code in bind_4.9.2 and prior, ie gethostbyaddr() does NOT do a forward lookup on the result it gets. It's quite easy to locate it in the sources of resolver, so if you added "pseudo" resolving modules to the libc, you're open to trivial DNS spoofing attack. Thus rshd rlogind and mountd as well as ypservd just call gethostbyaddr() which gets the bogus address. I think Steve Bellovin covered it pretty much in his paper. this is of course not new, and I think resolv+ has "anti-spoof" option, which is not on by default. Supposedly bind 4.9.3 fixes this, but I have accidently removed the srcs of 4.9.3 one I had here, and couldn't locate them anywhere, on ftp.uu.net it seems to be buried under some hidden directory, or something.. I was under impression that the brand new bug that Paul Vixie is working on was related to the recent "Internet-wide Nameserver Problems" when a site off of psi (I think ird.scitex.com -- wouldn't bet my life on it though) claimed root responsibility for "in-addr.arpa" (thus acted as Internet hostmaster) and as a result, it corrupted Internet root nameserver database. So if anyone on the net redefines the "IN-ADDR.ARPA" resource record on local nameserves, it'll cause reverse lookups to fall, and result of this serious problem is hard to predict. My other guess was that: it's quite easy to kill off a named daemon with a udp packet with an invalid length field, from remote site. But who knows, maybe this time it's something _really_ new with bind. My 0.2 $ --Me